Celestin Apprentice 2/Apprentice-Release2.iso/Information/Digests/CSMP Digest/volume 1/csmp-v1-128.txt

Text File | 1994-12-08 | 63.8 KB | 1,558 lines | [TEXT/R*ch]

C.S.M.P. Digest             Wed, 01 Jul 92       Volume 1 : Issue 128

Today's Topics:

    Think C vs. MPW



-------------------------------------------------------

From: [e-mail] (Jason Philip Stevens)
Subject: Think C vs. MPW
Date: 15 May 92 17:20:58 GMT
Organization: Baylor College of Medicine, Houston, Tx



How do people compare Think C to MPW?  I understand that MPW has a fairly
steep learning curve (it has been described as distinctly non-mac-like to me),
but from what I have heard it sounds more powerful than Think C.  Is there
any kind of consensus?
- --
Jason Stevens            Phone: [phone]
Network User Services        FAX: [phone]
Baylor College of Medicine    InterNet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Steve Dorner)
Organization: University of Illinois at Urbana-Champaign
Date: Fri, 15 May 1992 18:15:48 GMT

[e-mail] (Jason Philip Stevens) writes:
>How do people compare Think C to MPW?  I understand that MPW has a fairly
>steep learning curve (it has been described as distinctly non-mac-like to me),
>but from what I have heard it sounds more powerful than Think C.  Is there
>any kind of consensus?

MPW is slow and eats hardware like candy.  Now that I have a Quadra, I
can compare my compile times favorably to my brethren with THINK C and
Mac Plus'es.

It is very much like UNIX.  If you like UNIX a little, you'll like MPW.
Unfortunately, if you like UNIX a lot, you'll hate MPW, since you'll always
be bumping your nose into arbitrary differences.

On the other hand, if you want to do mixed language development, or
preprocess your source files, or do other weird stuff, MPW is the way to go.

- --
Steve Dorner, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner

+++++++++++++++++++++++++++

From: [e-mail] (Steve Poole)
Organization: Walker Richer & Quinn
Date: Fri, 15 May 1992 21:06:00 GMT

In article <[e-mail]>, [e-mail] (Steve Dorner) writes:
>
> On the other hand, if you want to do mixed language development, or
> preprocess your source files, or do other weird stuff, MPW is the way to go.

In that vein, MPW saves a great deal of time if you're doing stuff
with multiple code resources, like CTB tools.  In ThC each of the
resources must be a separate project and linking is a multiple-step,
interactive process.  With MPW you can automate the whole thing
very smoothly with make files.  Its background performance is
pretty respectable, too, if that's important to you.

- --------------------------------------------------------------------------
- -- INTEL 80x86: Just say NOP -- Internet: [e-mail] -- AOL: Spoole --
- --------------------------------------------------------------------------


+++++++++++++++++++++++++++

From: [e-mail] (Fred Walsteijn)
Organization: Physics Department, University of Utrecht,  The Netherlands
Date: Fri, 15 May 1992 21:21:09 GMT

In <[e-mail]> [e-mail] (Steve Dorner) writes:

>Unfortunately, if you like UNIX a lot, you'll hate MPW, since you'll always
>be bumping your nose into arbitrary differences.

Not true.  I like Unix a lot, but I like MPW even more: for me it combines most
advantages of Unix with the ease of use of the Mac.

>On the other hand, if you want to do mixed language development, or
>preprocess your source files, or do other weird stuff, MPW is the way to go.

True.  I use Fortran and C in the MPW Shell. Geee, that's weird ! :-)))
- -----------------------------------------------------------------------------
Fred Walsteijn                                | Internet: [e-mail]
Institute for Marine and Atmospheric Research | FAX:      [phone]
Utrecht University, The Netherlands           | Phone:    [phone]

+++++++++++++++++++++++++++

From: [e-mail] (Anders Wallgren)
Organization: Verity, Inc., Mountain View, CA
Date: Sat, 16 May 92 23:20:22 GMT

In article <[e-mail]>, walsteyn@fys (Fred Walsteijn) writes:
>In <[e-mail]> [e-mail] (Steve Dorner) writes:
>
>>Unfortunately, if you like UNIX a lot, you'll hate MPW, since you'll always
>>be bumping your nose into arbitrary differences.
>
>Not true.  I like Unix a lot, but I like MPW even more: for me it combines most
>advantages of Unix with the ease of use of the Mac.
>

I agree - the _only_ reason that I still prefer Unix to MPW is simple
- - GNU Emacs.  It is by far the most useful tool I use.

anders

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 18 May 92 05:09:03 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Steve Poole) writes:
> In article <[e-mail]>, [e-mail] (Steve Dorner) writes:
>>
>> On the other hand, if you want to do mixed language development, or
>> preprocess your source files, or do other weird stuff, MPW is the way to go.
>
> In that vein, MPW saves a great deal of time if you're doing stuff
> with multiple code resources, like CTB tools.  In ThC each of the
> resources must be a separate project and linking is a multiple-step,
> interactive process.  With MPW you can automate the whole thing
> very smoothly with make files.

Amen! Another example of multiple code resources is when you're developing
a set of related XCMDs and XFCNs for HyperCard (something I seem to
be doing a lot of lately). If I make a change to a common interface file,
I can trigger a rebuild of all the affected code resources automatically.

And as new, odd kinds of code resources come along, you can make up
a build procedure to deal with them--no need to wait for Apple or THINK
to come up with a new build option! Comms Toolbox tools are one example
mentioned above: others are After Dark modules, custom effects and
filters for Adobe Premiere, and so on--you can't seriously expect the
development environment vendor to provide options for building all of
these. For somebody like me who likes to dabble in such things, MPW is
paradise.

Alan Kay is credited with the statement "Simple things should be simple,
and complex things should be possible." I think this sums up the THINK
environments very well. Trouble is, complex things need to be more than
possible--it has to be *feasible* to attempt them. MPW doesn't make simple
things simple to do, but it has the power that is essential for attempting
the complex things.

Someday someone will come up with an environment that makes simple things
simple, and complex things feasible. When that happens, I'll be just as
happy to abandon MPW as I am to use it now.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00

+++++++++++++++++++++++++++

From: [e-mail] (Jason Philip Stevens)
Date: 18 May 1992 16:50:36 GMT
Organization: Baylor College of Medicine, Houston, Tx


> Alan Kay is credited with the statement "Simple things should be simple,
> and complex things should be possible." I think this sums up the THINK
> environments very well. Trouble is, complex things need to be more than
> possible--it has to be *feasible* to attempt them. MPW doesn't make simple
> things simple to do, but it has the power that is essential for attempting
> the complex things.

The question, of course, is at what price does this power come?  The word on the
street is that while MPW may make the complex possible, it also makes simple
tasks needlessly complex.  Is this true?  I don't need to make my programming
any more difficult than it already is...

>>I like Unix a lot, but I like MPW even more: for me it combines most
>>advantages of Unix with the ease of use of the Mac.

>I agree - the _only_ reason that I still prefer Unix to MPW is simple
>- GNU Emacs.  It is by far the most useful tool I use.

If true, great!  (I always resented that Macs didn't have shells;  I can't wait
for Apple to finally release it's scripting language...)

My last point (which I stupidly forgot to mention in my original post) was that
I'm stuck on an original Mac II (at least with a 105mb disk and 5MB RAM).  Is this
going to be sufficient, and not intolerably slow?

I must admit to being surprised by the favorable response MPW got; I had expected
to hear a few die-hard MPW fanatics being put down by a vast crowd of Think C
users.

- -Jason Stevens                [e-mail]
 Network User Services            [phone]
 Baylor College of Medicine        Opinions expressed are mine alone.
- --
Jason Stevens            Phone: [phone]
Network User Services        FAX: [phone]
Baylor College of Medicine    InterNet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 18 May 92 21:19:18 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Anders
Wallgren) writes:
> I agree - the _only_ reason that I still prefer Unix to MPW is simple
> - GNU Emacs.  It is by far the most useful tool I use.

I'm curious, if Apple would make a new development environment including
new editors, would GNU key-bindings be something people would ask for?
I guess most of you know of Alpha (the Emacs style MacOS editor).

Cheers,
Kent
PS: Yes, Emacs editors are also something close to my heart, fortunately
FRED (Fred Resembles Emacs Deliberately) in MCL is available.

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 19 May 92 02:47:05 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Jason
Philip Stevens) writes:
> I must admit to being surprised by the favorable response MPW got; I had
expected
> to hear a few die-hard MPW fanatics being put down by a vast crowd of Think C
> users.

You know, the secret is that both environments are good for different
situations.

Cheers,
Kent

+++++++++++++++++++++++++++

From: [e-mail] (Anders Wallgren)
Date: 20 May 92 01:06:38 GMT
Organization: Verity, Inc., Mountain View, CA

In article <[e-mail]>, ksand@apple (Kent Sandvik) writes:
>In article <[e-mail]>, [e-mail] (Anders
>Wallgren) writes:
>> I agree - the _only_ reason that I still prefer Unix to MPW is simple
>> - GNU Emacs.  It is by far the most useful tool I use.
>
>I'm curious, if Apple would make a new development environment including
>new editors, would GNU key-bindings be something people would ask for?
>I guess most of you know of Alpha (the Emacs style MacOS editor).
>

I think the key to emacs isn't so much the key bindings (I don't think
this is really what you meant), as much as the flexibility and
features (the 'neat' to the 'essential', but not in any particular
order):

  o Electric parentheses and braces for c, or whatever language you
    use since you can roll your own with emacs lisp
  o Knowledge about how code is formatted (very valuable when
    programmers with divergent styles work together)
  o I can compile from within emacs
  o I can check files in and out
  o I can go through error lists from my compile within emacs
  o I can jump through tags searches quickly
  o I can read mail
  o I can read News
  o Emacs lisp

All this is very fast and efficient, and if I don't like some
particular aspect of it, I can usually change it.

Many other environments/editors provide most, if not all this
functionality, but none as well as Emacs.

Perhaps it's the lack of context switching that I like.  If Apple does
manage to produce the next generation development environment with all
this 'stuff' available from within one context (implemented, perhaps,
as small cooperating units) then this would clearly be A Good Thing.

It is important to note, however, that performance and usability are
very important.  I have tags packages for MPW (including 411) that
have the same functionality as etags for emacs, but they are much
slower, or lacking in other ways.

MacBrowse is a wonderful example of a truly useful tool - I love it
and use it to browse (and to some extent, edit) all my MacApp code.  I
wish I could use it for _all_ our code, but since we have our own C
macro environment for declaring and defining functions, I can't just
feed those C files to MacBrowse, because it doesn't understand them.
etags (which generates tags files for emacs) was easy to extend to
accomodate this, so it continues to be a generically useful tool,
whereas MacBrowse gets used only on one small part of our product.

anders

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 20 May 92 06:50:07 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Jason Philip Stevens) writes:
> The question, of course, is at what price does [the power of MPW] come?  The
> word on the street is that while MPW may make the complex possible, it also
> makes simple tasks needlessly complex.  Is this true?  I don't need to make
> my programming any more difficult than it already is...

I must admit I'm biased, as I had several years of PDP-11 and VAX experience
before I discovered the Mac. (In mitigation, I would like to point out that
my favourite word processor is MacWrite II, so there.)

MPW is based a lot around typing of commands to do things. There are ways
to shortcut this process, by assigning command sequences to custom menu items
for example, and there's always online help and "Commando" to help you when
you're stuck.

If you're building a straightforward application, with all the code in
ordinary CODE segments, then I would say that MPW makes things harder than
THINK. But if you have e g custom WDEFs, CDEFs, MDEFs, LDEFs and the like,
then, as I understand it, the THINK environments require that you build these
as separate "projects". If they depend on common data which is shared with
your application mainline, then things start to get more complicated (you'd
have to manually recompile the separate projects in THINK if you made a change
to the common data), but with MPW it is still possible to put the appropriate
commands into one Makefile, so all the steps of the rebuild can be triggered
automatically.

> If true, great!  (I always resented that Macs didn't have shells;  I can't
> wait for Apple to finally release it's scripting language...)

MPW *is* a shell, and as such has uses beyond program development. And while
it may lack a few UNIX niceties, it can also show UNIX systems a trick or two.

For example, I'm responsible for our departmental AppleShare server, and twice
now we've upgraded one of its hard disks to a bigger model. In each case,
I had the job of moving all the files from the old hard disk to the new one,
preserving all the folder ownerships and protections. Doubtless there are
commercial backup/restore utilities that will do this for you, but I managed
it using just the Finder and MPW.

I copied the files across by hooking both disks up to the server machine,
logging on as the privileged user, and just dragging the folders across with
the Finder. Naturally this reverted all the folder protections to some totally
useless default.

Then I used MPW's "SetPrivilege" command. This lets you examine and change
folder ownerships and protections. The useful feature here is, when you
examine the protection on a folder, it displays it in the form of a
"SetPrivilege" command (in fact this is a common convention with other MPW
commands). This means you can select the output and execute it as a command,
for example to restore a setting after temporarily changing it.

What I did was use the following command:

    SetPrivilege -i -r OldVolume:

"-i" means display existing protections, "-r" means do it recursively for
all inner folders as well. This output a whole series of SetPrivilege commands
for all the folders on the old disk.

I then did a global search and replace on the output, changing all references
to "OldVolume" to make it "NewVolume". Next I selected all the modified
SetPrivilege commands and executed them. Voila! An exact copy of the old
protection structure on the new volume!

Is that power, or is that power...

> My last point (which I stupidly forgot to mention in my original post) was
> that I'm stuck on an original Mac II (at least with a 105mb disk and 5MB
> RAM).  Is this going to be sufficient, and not intolerably slow?

I can categorically state that MPW itself will run just fine. I ran it for
years on my vintage Mac II at work before it was upgraded (a few months ago)
to a IIfx. In fact these days I do most of my development on my LC at home, and
I find that a perfectly usable configuration. Last I checked, it took about
15 seconds for MPW to start up, because it executes all these custom commands
I have in my startup script to set up the environment the way I want it.

The thing about MPW is that it's relatively memory-hungry: Apple's compilers
work best if the Shell has a couple of megs of RAM; the SADE symbolic debugger
takes another meg at least, and you may want to save the time it takes to
quit and restart the Shell while running (and debugging) your program, so
you have to add your program's memory requirements to these. I'd say 5 megs
would give you close to a meg free for your program under System 7. What the
hell, take your machine to 8 megs--it's not an exorbitant cost.

The thing for which you would need all the CPU power you can get is MacApp
compiles (Hiya Bruce--maybe you'd like to tell us more about that :-)).

> I must admit to being surprised by the favorable response MPW got; I had
> expected to hear a few die-hard MPW fanatics being put down by a vast crowd
> of Think C users.

Fanatics? Us humble MPW hackers?? Whatever gave you that idea...?

Lawrence "If It Can't be Done in MPW, It Isn't Worth Doing" D'Oliveiro

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Neeracher)
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: Wed, 20 May 1992 12:24:03 GMT

In article <[e-mail]> [e-mail] (Kent Sandvik) writes:
>In article <[e-mail]>, [e-mail] (Anders
>Wallgren) writes:
>> I agree - the _only_ reason that I still prefer Unix to MPW is simple
>> - GNU Emacs.  It is by far the most useful tool I use.
>
>I'm curious, if Apple would make a new development environment including
>new editors, would GNU key-bindings be something people would ask for?

What I'd really like to have is a way to call editor primitives from other
languages than the shell script language. Implementing *exact* Emacs
compatibility in a Mac editor is IMHO undesirable (The point-mark paradigma is
incompatible with the UI guidelines.

Something liek Emacs lisp would also be nice :-)

Matthias

- -----
Matthias Neeracher                                      [e-mail]
  "Nur die halbe Welt ist Teflon und Asbest" -- Einstuerzende Neubauten

+++++++++++++++++++++++++++

From: [e-mail] (Jason Philip Stevens)
Date: 20 May 1992 15:39:00 GMT
Organization: Baylor College of Medicine, Houston, Tx


In article <[e-mail]>, [e-mail] (Kent Sandvik) writes:
|> In article <[e-mail]>, [e-mail] (Anders
|> Wallgren) writes:
|> > I agree - the _only_ reason that I still prefer Unix to MPW is simple
|> > - GNU Emacs.  It is by far the most useful tool I use.
|>
|> I'm curious, if Apple would make a new development environment including
|> new editors, would GNU key-bindings be something people would ask for?
|> I guess most of you know of Alpha (the Emacs style MacOS editor).

Definitely.  Also (as a mostly complete aside) it would be nice to have them
in TeachText, too.

- -jps
- --
Jason Stevens            Internet:  [e-mail]
Network User Services        Voice:  [phone]
Baylor College of Medicine    Opinions expressed are mine alone.


+++++++++++++++++++++++++++

From: [e-mail] (Jason Philip Stevens)
Date: 20 May 92 15:55:11 GMT
Organization: Baylor College of Medicine, Houston, Tx


In article <[e-mail]>, [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:

>> I must admit to being surprised by the favorable response MPW got; I had
>> expected to hear a few die-hard MPW fanatics being put down by a vast crowd
>> of Think C users.
>
>Fanatics? Us humble MPW hackers?? Whatever gave you that idea...?
>
>Lawrence "If It Can't be Done in MPW, It Isn't Worth Doing" D'Oliveiro

Good advertising (both formal and word of mouth) for Symantec :)

- -jps
- --
Jason Stevens            Internet:  [e-mail]
Network User Services        Voice:  [phone]
Baylor College of Medicine    Opinions expressed are mine alone.

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 20 May 92 19:38:53 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Anders Wallgren)
writes:
> I think the key to emacs isn't so much the key bindings (I don't think
> this is really what you meant), as much as the flexibility and
> features (the 'neat' to the 'essential', but not in any particular
> order):
>
>   o Electric parentheses and braces for c, or whatever language you
>     use since you can roll your own with emacs lisp
>   o Knowledge about how code is formatted (very valuable when
>     programmers with divergent styles work together)
>   o I can compile from within emacs
>   o I can check files in and out
>   o I can go through error lists from my compile within emacs
>   o I can jump through tags searches quickly
>   o I can read mail
>   o I can read News
>   o Emacs lisp

What you propose is a huge change in the current MPW editor,
and a lot of work in a future programmer editor. It is true
that key bindings are just one aspect, but I like the idea
of jumping around, setting marks, and using the circular-ring
buffer, and it would certainly be nice to have these bindings
in any programmer editors.

Hopefully better AppleEvent support with development tools would
dissolve the issue of using integrated editors. For instance
if Alpha would support ToolServer and SourceServer it would be
easy to work from a single editor environment. I'm also hinting
at possible feature upgrades in the current MacOS programmer
editors, and if I remember correctly Qued/M has implemented some
of the AE support already.

Cheers,
Kent

+++++++++++++++++++++++++++

From: [e-mail] (Jason Philip Stevens)
Date: 21 May 1992 15:47:55 GMT
Organization: Baylor College of Medicine, Houston, Tx


In article <[e-mail]>, [e-mail] (Kent Sandvik) writes:
|> In article <[e-mail]>, [e-mail] (Anders Wallgren)
|> writes:
|> > I think the key to emacs isn't so much the key bindings (I don't think
|> > this is really what you meant), as much as the flexibility and
|> > features (the 'neat' to the 'essential', but not in any particular
|> > order):

[list of valuable features deleted]

|> What you propose is a huge change in the current MPW editor,
|> and a lot of work in a future programmer editor. It is true
|> that key bindings are just one aspect, but I like the idea
|> of jumping around, setting marks, and using the circular-ring
|> buffer, and it would certainly be nice to have these bindings
|> in any programmer editors.

True.  While the mac's "ease of use" is a real selling point, it has the
unfortunate tendency to become a misnomer when the user interface gets in the
way of what you want to do.  This simple change would make processing code much
easier, and as an added bonus it adheres to a standard that many of the UNIX
folks coming to the mac (borrowed from another thread ;) can recognize and use.

Which is not to say that the other features shouldn't be implemented too, if you
get the chance, of course.

- -jps

- --
Jason Stevens            Internet:  [e-mail]
Network User Services        Voice:  [phone]
Baylor College of Medicine    Opinions expressed are mine alone.


+++++++++++++++++++++++++++

From: [e-mail] (Anders Wallgren)
Organization: Verity, Inc., Mountain View, CA
Date: Thu, 21 May 92 19:11:36 GMT

In article <[e-mail]>, ksand@apple (Kent Sandvik) writes:
>In article <[e-mail]>, [e-mail] (Anders Wallgren)
>writes:
    [Lots of things about Gnu Emacs]
>
>What you propose is a huge change in the current MPW editor,
>and a lot of work in a future programmer editor. It is true
>that key bindings are just one aspect, but I like the idea
>of jumping around, setting marks, and using the circular-ring
>buffer, and it would certainly be nice to have these bindings
>in any programmer editors.

I was not proposing this as a future direction for the new Mac
development environment.  Indeed, since a stated goal of the new
environment is to make it easy to learn, I think many of these
features would be difficult to implement under this constraint - I
don't know of anyone that has ever claimed that learning all the
powerful features of emacs was easy.

Instead, what I wrote was kind of a clumsy way of saying that keyboard
bindings aren't the end-all of what makes a programming environment or
editor easy to use, or powerful for that matter.  If that were the
case, I would have used QuicKeys to rebind down arrow to ^n long
ago...

>Hopefully better AppleEvent support with development tools would
>dissolve the issue of using integrated editors. For instance
>if Alpha would support ToolServer and SourceServer it would be
>easy to work from a single editor environment. I'm also hinting
>at possible feature upgrades in the current MacOS programmer
>editors, and if I remember correctly Qued/M has implemented some
>of the AE support already.

I agree. As you will recall, part of my list of things that makes
emacs great is the ability to compile and find compiler errors from
within emacs.  This isn't because emacs is an 'integrated editor,' but
rather it is the Unix shell environment makes this possible.  On the
Mac, AppleEvents will (hopefully) be the enabling technology for doing
this type of thing.

anders

+++++++++++++++++++++++++++

From: [e-mail] (John Nagle)
Date: Fri, 22 May 92 02:13:03 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

      I just wish MPW followed the Apple User Interface Guidelines and
the Mac design philosophy, instead of being a reimplementation of PWB/UNIX.

      The UNIX text-file orientation is obsolete.  The build controller,
linker, source code management system, and debugger should all run off
the same representation of the program structure, and that structure
should be accessable through a suitable Mac metaphor.  You should never
have to tell the computer something it already knows.  MPW is a long
way from that.

      Remember, MPW was implemented in a rush to get something going
that would allow Mac development on a Mac.  They picked the UNIX model,
which was known to work, and ran with it.  But it's obsolete.

                    John Nagle

+++++++++++++++++++++++++++

From: [e-mail] (John Galidakis)
Date: 22 May 92 04:27:14 GMT
Organization: University of Illinois at Chicago

John Nagle writes: >[...stuff deleted]>
Remember, MPW was implemented in a rush to get something going
that would allow Mac development on a Mac.  They picked the UNIX model,
which was known to work, and ran with it.  But it's obsolete.
>
Well said, brother! Another reasonable human being who has not been taken
(or should I say "swept over") by the UNIX hype.
UNIX implementations are for dum machines that need to be told explicitly
what to do. Any UNIX has no place on the mac. The mac has been created
to be intuitive, friendly and easy to use. That ingenious forsight has
made mac programming MUCH HARDER for us than for big blue guys.(since the
programmer is the one who solves the "dificulty" burden) As if this was
not enough, here comes UNIX to make things that already work, work less
intuitively. Or is it that mac programmers are *excluded* from the
"intuitive" and "friendly" directive?? Part of what made me LOVE the mac,
is the additional challenge of programming it. But hey, if I wanted to
program a dinosaur, I'd pick a blue clone.
 UNIX on the mac reminds me of three-D chess. (aka "star trek" chess)
the idea is obsolete, at the moment it is concieved: regular chess
is already three dimentional (and hard enough). So why make it harder??
Sheeshh...                        _______
John "the Baptist" Galidakis      \     /
math grad.                         \   /
                                    \|/

+++++++++++++++++++++++++++

From: [e-mail] (Steve Dorner)
Organization: University of Illinois at Urbana-Champaign
Date: Fri, 22 May 1992 14:49:02 GMT

[e-mail] (John Nagle) writes:
>      The UNIX text-file orientation is obsolete.  The build controller,
>linker, source code management system, and debugger should all run off
>the same representation of the program structure, and that structure
>should be accessable through a suitable Mac metaphor.

Didn't you just describe (mostly) THINK C?  And hasn't the consensus been
that THINK C is just great, unless you want to do <insert weird thing here>?

I suggest that the inability to do "weird things" is the stumbling block
in the environment you want.

Or let me put it another way:  "Text-based languages are obsolete.  We
should only use things like Helix or Prograph to write applications."

Some people probably believe this.  I don't.  I don't think visual "languages"
like this give the programmer enough flexibility.  Similarly with a GUI
programming environment; I WANT to be able to program my programming
environment, because I don't think anyone is going to be able to anticipate
my every desire.

I *want* to be able to sic my text processors on my Makefiles, because
they let me do strange and wonderful things that I can't imagine Mike Kahl
thinking of.  (Sorry, Mike, maybe I'm underestimating you :-))

Isn't one of the Real Big Deals coming out from Apple going to be AppleScript,
where you can use one of these obsolete clunky old text files to drive
your GUI?

>You should never
>have to tell the computer something it already knows.

Yes, and I'd be very happy to see more cooperation amongst the various bits
that know the various things.
- --
Steve Dorner, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner

+++++++++++++++++++++++++++

From: [e-mail] (Jason Philip Stevens)
Date: 22 May 92 17:10:55 GMT
Organization: Baylor College of Medicine, Houston, Tx


In article <[e-mail]>, [e-mail] (John Galidakis) writes:
|> John Nagle writes: >[...stuff deleted]>
|> Remember, MPW was implemented in a rush to get something going
|> that would allow Mac development on a Mac.  They picked the UNIX model,
|> which was known to work, and ran with it.  But it's obsolete.
|> >
|> Well said, brother! Another reasonable human being who has not been taken
|> (or should I say "swept over") by the UNIX hype.
|> UNIX implementations are for dum machines that need to be told explicitly
|> what to do. Any UNIX has no place on the mac. The mac has been created
|> to be intuitive, friendly and easy to use. That ingenious forsight has
|> made mac programming MUCH HARDER for us than for big blue guys.(since the
|> programmer is the one who solves the "dificulty" burden) As if this was
|> not enough, here comes UNIX to make things that already work, work less
|> intuitively. Or is it that mac programmers are *excluded* from the
|> "intuitive" and "friendly" directive?? Part of what made me LOVE the mac,
|> is the additional challenge of programming it. But hey, if I wanted to
|> program a dinosaur, I'd pick a blue clone.
|>  UNIX on the mac reminds me of three-D chess. (aka "star trek" chess)
|> the idea is obsolete, at the moment it is concieved: regular chess
|> is already three dimentional (and hard enough). So why make it harder??

Wait a second!  I started with the mac when the fat mac was released, loved it
then, and love it now.  But IMHO, the user interface can step on the toes of a
"power user".  There are times when something needs to be done that an expert
could do in a second from a command line, that the GUI makes you do step by
tedious step, asking you "Are you sure?" and "Are you sure you're sure?" with
every click of the mouse.  I agree with you that the GUI is a *good thing*, but
don't disparage the power of the command line, either.  The weakness of one is
the strength of the other, and each is useful for its own set of tasks.

- -jps
- --
Jason Stevens            Internet:  [e-mail]
Network User Services        Voice:  [phone]
Baylor College of Medicine    Opinions expressed are mine alone.

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 22 May 92 18:46:21 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

> Isn't one of the Real Big Deals coming out from Apple going to be AppleScript,
> where you can use one of these obsolete clunky old text files to drive
> your GUI ?

Ah, AppleScript lets you roll your own dialect. For instance,
and iconized dialect...

- --
h++ - new and improved !

You never hide the menu bar. You might go about and make it the same
color as the background, but you never hide the menu bar.      - Tog

+++++++++++++++++++++++++++

From: [e-mail] (Steve Dakin)
Date: 22 May 92 22:03:12 GMT
Organization: Oceania Health Care Systems

In article <[e-mail]> [e-mail] (Jason
Philip Stevens) writes:
> I agree with you that the GUI is a *good thing*, but don't disparage the
> power of the command line, either.  The weakness of one is the strength
> of the other, and each is useful for its own set of tasks.

I completely agree with Jason.  Not to beat a dead horse (CLI vs. GUI), but I
like concrete examples, and I just happen to have one.  One of the things I do
VERY often in programming is searching text files for occurrences of some key
word - either to correct an error, change a variable name or type, or a wide
assortment of other actions.  In MPW (our CLI example), I can search a whole
directory of files for a string and see all occurrences listed at once for me,
as opposed to going through each file individually until I hear a beep
indicating my search is finished (the way THINK C does it).  That one feature,
along with being able to search a directory that is not the current project
directory (like the 'includes' directory, for example) is winning me over to
MPW (at least for now).  But (I must present both sides of the dead horse,
right), there is one feature that drives me absolutely batty about MPW's CLI --
and that is going to a specific line number in a file.  In THINK, this is
simple - in MPW, it's absolutely assinine.  First, I have to make the desired
file's window frontmost, then switch back to the Worksheet window.  This gives
that magical "second-most active" status to the window in which I want to
execute the command.  Then I type 'find <line #>' and hit <enter> (not return,
mind you, because although that is the standard command execution key, it
doesn't execute commands in MPW).  Now, I must switch back to the other window
and finally, the line I want to go to is selected.  What a pain!

So to make my unfortunately long story short - neither interface will be far
superior enough to other one, and we might as well get used to having them both
around.  THINK with a good set of utilities and the ability to support multiple
language .o files would make MPW a tough choice.

- -Steve
- --
    Steve Dakin                      Oceania Health Care Systems
 [e-mail] (NeXT mail)       Palo Alto, CA [phone]
 [e-mail]                  "That one deserves a ... WOW!"

+++++++++++++++++++++++++++

From: [e-mail] (Rich Siegel)
Date: 23 May 92 04:54:05 GMT
Organization: GCC Technologies

In article <[e-mail]> [e-mail] writes:

>assortment of other actions.  In MPW (our CLI example), I can search a whole
>directory of files for a string and see all occurrences listed at once for me,
>as opposed to going through each file individually until I hear a beep
>indicating my search is finished (the way THINK C does it).  That one feature,
>along with being able to search a directory that is not the current project
>directory (like the 'includes' directory, for example) is winning me over to
>MPW (at least for now).  But (I must present both sides of the dead horse,

    BBEdit can do this; there's a batch mode which accumulates the
results into a list window; you can then double-click on an entry to
display the occurrence. No command lines involved.

R.



- --
- -----------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Software Engineer & Toolsmith
GCC Technologies

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 22 May 92 19:14:44 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (John
Galidakis) writes:
>
> John Nagle writes: >[...stuff deleted]>
> Remember, MPW was implemented in a rush to get something going
> that would allow Mac development on a Mac.  They picked the UNIX model,
> which was known to work, and ran with it.  But it's obsolete.

Another insight oldtimers to development environments know of, is that
never will *one single* development environment solve all the needs of
programmers.

The key to a successful development environment is flexibility, so developers
are able to extend the environment using simple primitives, building complex
functions from simple rules.

The UNIX model supports this idea, which is one reason I wouldn't clearly
state that UNIX is obsolete, it actually showed the way for reusable
tools and components (sed, awk, built-in compiler, libraries, and so on...).

UNIX still have a lot of ancient building blocks though, files on disk,
non-dynamic development environments and so on, but things change all
the time.

> Well said, brother! Another reasonable human being who has not been taken
> (or should I say "swept over") by the UNIX hype.

Any paradigm could be turned to hype, usually this is done by marketroids,
and not the hackers.

> UNIX implementations are for dum machines that need to be told explicitly
> what to do. Any UNIX has no place on the mac. The mac has been created
> to be intuitive, friendly and easy to use. That ingenious forsight has
> made mac programming MUCH HARDER for us than for big blue guys.(since the
> programmer is the one who solves the "dificulty" burden) As if this was
> not enough, here comes UNIX to make things that already work, work less
> intuitively. Or is it that mac programmers are *excluded* from the
> "intuitive" and "friendly" directive?? Part of what made me LOVE the mac,
> is the additional challenge of programming it. But hey, if I wanted to
> program a dinosaur, I'd pick a blue clone.

Once again I would not be that quick to just forget any of the good ideas
which UNIX provided us. Clever artists steal from other environments, you
know :-).
- --
                                              Cheers, Kent


+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 22 May 92 22:08:31 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail]
(Jon W{tte) writes:
> > Isn't one of the Real Big Deals coming out from Apple going to be
AppleScript,
> > where you can use one of these obsolete clunky old text files to drive
> > your GUI ?

> Ah, AppleScript lets you roll your own dialect. For instance,
> and iconized dialect...

..or Romulan! Who's the first one to make this wild AppleScript hack?
- --
                                              Cheers, Kent


+++++++++++++++++++++++++++

From: [e-mail] (Sak Wathanasin)
Date: 24 May 92 19:43:15 GMT
Organization: Network Analysis Ltd


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Steve Dakin) writes:

> But (I must present both sides of the dead horse,
> right), there is one feature that drives me absolutely batty about MPW's CLI --
> and that is going to a specific line number in a file.  In THINK, this is
> simple - in MPW, it's absolutely assinine.  First, I have to make the desired
> file's window frontmost, then switch back to the Worksheet window.  This gives
> that magical "second-most active" status to the window in which I want to
> execute the command.  Then I type 'find <line #>' and hit <enter> (not return,
> mind you, because although that is the standard command execution key, it
> doesn't execute commands in MPW).  Now, I must switch back to the other window
> and finally, the line I want to go to is selected.  What a pain!

So add a "Goto..." item to the Find menu. What's the problem? From my
UserStartUp file:

AddMenu Find "GotoI" opt-d
    '(Find opt-j`Request "Go to line?"` "{Active}"|| Beep) opt-> Dev:Null'

where opt-d = the small delta char, and opt-j = the triangle char, and opt->
= the greater-than-or-equals char. If you use it a lot, bind it to a func
key or whatever using SetKey.


Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

uucp:      ...!uknet!nan!sw  Phone: [phone]
AppleLink: NAN.LTD           Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Sak Wathanasin)
Date: 24 May 92 20:01:06 GMT
Organization: Network Analysis Ltd


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Anders Wallgren) writes:

> As you will recall, part of my list of things that makes
> emacs great is the ability to compile and find compiler errors from
> within emacs.  This isn't because emacs is an 'integrated editor,' but
> rather it is the Unix shell environment makes this possible.  On the
> Mac, AppleEvents will (hopefully) be the enabling technology for doing
> this type of thing.

Shhhh! Don't tell MPW it can't do that or what I do every day will
stop working (:-). Seriously though, check out the DTS Goodies
scripts on the ETO or develop CDs. With them, you can build a project
using cmd-B, or the last thing using opt-cmd-B. It uses opt-cmd-> and
opt-cmd-< for walking up and down the error list. Cmd-I checks in the
active window, cmd-J checks it out and so on.

I think the point you were trying to make though is that on Unix,
emacs, a standalone appl, is able to do these things by "talking" to
the shell and there needs to be a similar mechanism on the Mac. I
couldn't agree more, and AppleEvents does hold the key to this; for
example, look at what ObjectMaster can do with the MPW shell and
ToolServer as things stand.

Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

uucp:      ...!uknet!nan!sw  Phone: [phone]
AppleLink: NAN.LTD           Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Anders Wallgren)
Date: 25 May 92 00:35:33 GMT
Organization: Verity, Inc., Mountain View, CA

In article <[e-mail]>, sw@network-analysis-ltd (Sak Wathanasin) writes:
>Shhhh! Don't tell MPW it can't do that or what I do every day will
>stop working (:-). Seriously though, check out the DTS Goodies
>scripts on the ETO or develop CDs. With them, you can build a project
>using cmd-B, or the last thing using opt-cmd-B. It uses opt-cmd-> and
>opt-cmd-< for walking up and down the error list. Cmd-I checks in the
>active window, cmd-J checks it out and so on.
>

In fact, I use this, too, but half the time I eschew them because
they're just too slow for most of my day-to-day needs.

>I think the point you were trying to make though is that on Unix,
>emacs, a standalone appl, is able to do these things by "talking" to
>the shell and there needs to be a similar mechanism on the Mac. I
>couldn't agree more, and AppleEvents does hold the key to this; for
>example, look at what ObjectMaster can do with the MPW shell and
>ToolServer as things stand.

Agreed.

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 26 May 92 03:32:36 GMT
Organization: MacDTS Mongols

In article <keithley-5/25/92+7:19:27 PM@MagicCookie>, [e-mail] (Craig
Keithley) writes:
> This is what Projector gives you.  Think C lacks this (or did the last
> time I checked).  In my opinion, all "projects", no matter how small,
> should be under projector control.  Even my one file MPW tools and scripts
> are usually under projector control.  Projector can store its 'database'
> on a fileserver, so multi-person projects can share source code.  Projector
> will also tell you if someone else has updated a file (using the 'Select
> newer' button in the checkout dialog).

   The key for the future is SourceServer use, where SourceServer understands
AppleEvents concerning the Projector system it handles. Thus any development
environments that wants to get a 'there's no free lunch' project control
system only needs to implement the AEs and wrap a nice user interface
around this control. MCL has sample code for this, and I'm sure future
third party tools also will use this.

> Occasionally, even within Apple, I come across some poor soul who despises
> Configuration Management.  Who, blind to the dangers, exists purely at
> the whim of fate, carrying around multiple copies of the source.  In folders
> labeled 'xyzzy Rev 1.0a1', 'xyzzy Rev 1.0a2', and so on.  I wish them luck.

   We use this a lot for multi-programmer projects. I'm a little bit hesitant
to use it for my own hacks, but then I'm lazy. My complicated scheme is
to number every version I started working on (the folder where the source is),
and every time I release something externally I bounce up the major number.
I.e. 005 is a fresh hack, 1.00 is something I've released, and 1.05 is a
continuous update/feature enhancement. I have alpha/beta numbering, it
makes life too complicated *).
- --
                                              Cheers, Kent

*) I've seen this numbering on outside projects lately as well.

+++++++++++++++++++++++++++

From: [e-mail] (Pete Gontier)
Date: 27 May 92 02:22:53 GMT

[e-mail] (Steve Dakin) writes:
>right), there is one feature that drives me absolutely batty about MPW's CLI
>and that is going to a specific line number in a file. In THINK, this is
>simple - in MPW, it's absolutely assinine. First, I have to make the desired
>file's window frontmost, then switch back to the Worksheet window. This gives
> [ long tedious description of long tedium omitted ]

Next time an MPW compiler spits out an error at you, triple-click the line
that describes the error and hit 'enter'.

There, see? It's not so bad.
- --
 Pete Gontier // EC Technology // [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Cory Kempf)
Date: 27 May 92 03:47:07 GMT
Organization: EnigamI, Inc., Nashua, NH


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Kent Sandvik) writes:
>In article <[e-mail]>, [e-mail] (Anders Wallgren)
>writes:

>>   o Electric parentheses and braces for c, or whatever language you
>>     use since you can roll your own with emacs lisp
>>   o Knowledge about how code is formatted (very valuable when
>>     programmers with divergent styles work together)

>What you propose is a huge change in the current MPW editor,
>and a lot of work in a future programmer editor.

>Hopefully better AppleEvent support with development tools would
>dissolve the issue of using integrated editors.

Unfortunately, even if there were programmers out there who understood
appleevents (:-)) they wouldn't be able to solve basic deficiencies
in the editor's language handling capabilities.

The MPW editor should be designed to do one thing well, and that is
to edit code written in a programming language.  It really shouldn't
matter which one -- it should be sufficiently customizable to handle
any reasonable language.

Features like electric/eclectic C/C++ mode should be either built
into the editor, or addable.  The editor should be understand the
code sufficiently well enough to indent properly.

Anything less is a half assed job.  Anything less is not addressing
the problem at hand (assisting programmers to type in code), and is
probably addressing some other job (building a generic text editor
/ shell perhaps?).

Don't get me wrong, I like the MPW editor.  It has a lot of very powerful
features that I have not seen in any other editor.  But it is by no
means the last word in programming editors.  I think that it could use a
lot of work still.

While we are on the subject of useful enhancements, how about being
able to colour text?  Use multiple fonts?  faces?  sizes?  Howabout
being able to colapse sections of code?  A script compiler?  Integrated
tags?  Inside Mac VI savvy 411?  A better approach to segmentation?
Better printing support?  Better integration of the compiler error
output and the editor (perhaps something like the Goodies' compare
script), etc.

+C


- -------------------------------------------------------------
Cory Kempf                    EnigamI, Inc.
[e-mail]           ...!decvax!enigami!cory
Microsoft Free and Proud Of It!...
                           ...Microsoft Products: Just Say no.

+++++++++++++++++++++++++++

From: [e-mail] (Cory Kempf)
Date: 27 May 92 04:00:49 GMT
Organization: EnigamI, Inc., Nashua, NH


In article <[e-mail]> (comp.sys.mac.programmer), John Galidakis <[e-mail]> writes:
>John Nagle writes:
>>Remember, MPW was implemented in a rush to get something going
>>that would allow Mac development on a Mac.  They picked the UNIX model,
>>which was known to work, and ran with it.  But it's obsolete.

>Well said, brother! Another reasonable human being who has not been taken
>(or should I say "swept over") by the UNIX hype.
>    Any UNIX has no place on the mac.

The unix interface *IS* obsolete, true enough.  However, even as an
obsolete interface, it still provides a *LOT* of power.  There are
a lot of thing that I can do under unix that I just cannot do in Think
C, for example.

MPW is an incrimental improvement over unix is some areas (in others,
it is a step back).

This does not mean that we should abandon the power that the unix
interface gives to those that have mastered it.  Any new programming
interface that took away capabilities that I have now is a step backward,
not forward.  No matter how many icons/windows/menus/etc it has.

What is needed (IMNSHO) is for the people who are designing MPW to
take a step back, and rethink the whole idea.  From the ground up.
Start with some simple questions: What is the purpose of this product?
What are the people who will use it trying to do?  No, step back further,
what are they really trying to get done?  What kind of tools could
we design to assist in their real task?  How can we provide those
tools, without crippling our users?

Then take a look at the evolution of some Mac packages.  Look at the
evolution of MPW, and ask if what has been happening is the past three
years isn't another version of a glass tty (cf TOG).

I think that if someone gives some serious thought to these questions,
a MUCH better application development environment will result.  If
you are still stuck, you can always hire me as a consultant :-)

+C


- -------------------------------------------------------------
Cory Kempf                    EnigamI, Inc.
[e-mail]           ...!decvax!enigami!cory
Microsoft Free and Proud Of It!...
                           ...Microsoft Products: Just Say no.

+++++++++++++++++++++++++++

From: [e-mail] (Cory Kempf)
Date: 27 May 92 04:07:49 GMT
Organization: EnigamI, Inc., Nashua, NH


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Steve Dakin) writes:
>there is one feature that drives me absolutely batty about MPW's CLI --
>and that is going to a specific line number in a file.  In THINK, this is
>simple - in MPW, it's absolutely assinine.

[overly complex method deleted]

somewhere convenient (the worksheet) type:

file <filename>; line xxx <enter>

+C


- -------------------------------------------------------------
Cory Kempf                    EnigamI, Inc.
[e-mail]           ...!decvax!enigami!cory
Microsoft Free and Proud Of It!...
                           ...Microsoft Products: Just Say no.

+++++++++++++++++++++++++++

From: [e-mail] (Mel Walker)
Organization: Novell, Inc. - Walnut Creek
Date: Wed, 27 May 1992 14:50:47 GMT

In article <[e-mail]> [e-mail] writes:
>
>In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Kent Sandvik) writes:
>>In article <[e-mail]>, [e-mail] (Anders Wallgren)
>>writes:
>
>>>   o Electric parentheses and braces for c, or whatever language you
>>>     use since you can roll your own with emacs lisp
>>>   o Knowledge about how code is formatted (very valuable when
>>>     programmers with divergent styles work together)
>
>>What you propose is a huge change in the current MPW editor,
>>and a lot of work in a future programmer editor.
>
>>Hopefully better AppleEvent support with development tools would
>>dissolve the issue of using integrated editors.
>
>Unfortunately, even if there were programmers out there who understood
>appleevents (:-)) they wouldn't be able to solve basic deficiencies
>in the editor's language handling capabilities.
>
>The MPW editor should be designed to do one thing well, and that is
>to edit code written in a programming language.  It really shouldn't
>matter which one -- it should be sufficiently customizable to handle
>any reasonable language.
>
[...deleted...]

I must disagree. The MPW editor should be designed to do _several_ things
well. We often use it for intensive text processing of testing reports
from automated tests. We can take a raw report from an automated test tool
and generate a summary, or several sub-reports, and link them together in
a hypertext kind of approach, as well as generate Excel-readable reports. I
don't want to lose all that just because someone wants a better editor. I
agree, the MPW editor doesn't compare with some, but with AppleEvents someone
should be able to use ToolServer with some other editor to get the job done.

Really, of course, MPW should be all things to all people. <g>

- --
+------------------------------+---------------------------------------------+
+ Mel Walker                   | ******** Dave Barry for President ********* +
+ [e-mail] | "He may be a Homicidal Axe Murderer, but at +
+                              |      least he won't raise your taxes!"      +

+++++++++++++++++++++++++++

From: [e-mail]
Date: 27 May 92 13:15:06 EDT
Organization: Cornell University

If my recollection is correct, the original question which started this
thread was about _compilers_, and I was hoping to see some commentary
about the relative merits of the MPW v. Think C compilers.  Does anybody
have any opinions on which of them generates more efficient code, in
terms of size or speed?

Tim Dorcey

+++++++++++++++++++++++++++

From: [e-mail] (Jason Philip Stevens)
Date: 27 May 1992 19:38:44 GMT
Organization: Baylor College of Medicine, Houston, Tx


In article <[e-mail]>, [e-mail] writes:
|> If my recollection is correct, the original question which started this
|> thread was about _compilers_, and I was hoping to see some commentary
|> about the relative merits of the MPW v. Think C compilers.  Does anybody
|> have any opinions on which of them generates more efficient code, in
|> terms of size or speed?

Actually, the original thrust of the thread _was_ about which product provided
a better development environment (I can say that, I started it ;).  But you
have a good point;  in all the mail I got and all the postings I've seen no
one has addressed the quality of output code.  Any takers?

- -jps



- --
Jason Stevens            Internet:  [e-mail]
Network User Services        Voice:  [phone]
Baylor College of Medicine    Opinions expressed are mine alone.


+++++++++++++++++++++++++++

From: [e-mail] (Mustafa Thamer)
Organization: Numerical Design Limited
Date: Wed, 27 May 1992 19:48:21 GMT

The main reason that we use MPW C++ is its command-line interface.
We have a production system where source code is developed on Suns
and exported to the Mac (or other machines) for platform specific
compilation.  We are able to drive MPW remotely from the Suns
by sending compile commands to MPW's CLI from make scripts on the Sun.

I don't think this is possible with ThinkC, is it?  If so, we'd
probably use it since it's so much faster.

- -Mustafa

- --
Two days ago I saw a vehicle that'd haul that tanker.
You wanna get out of here - you talk to me.
    - Max, The RoadWarrior

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 28 May 92 01:02:58 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Cory
Kempf) writes:
> While we are on the subject of useful enhancements, how about being
> able to colour text?  Use multiple fonts?  faces?  sizes?  Howabout
> being able to colapse sections of code?  A script compiler?  Integrated
> tags?  Inside Mac VI savvy 411?  A better approach to segmentation?
> Better printing support?  Better integration of the compiler error
> output and the editor (perhaps something like the Goodies' compare
> script), etc.

   Most of those notes are taken, and understood by those who are working
on the next generation of development tools and editors.

   Sometimes I just hope that AEs would be the glue, and we had various
editors, compilers and development environments who talk with each
other using the same protocol. I have a dream..
- --
                                              Cheers, Kent



+++++++++++++++++++++++++++

From: [e-mail] (Paul Potts)
Organization: Instructional Technology Laboratory, University of Michigan
Date: Thu, 28 May 92 13:52:27 GMT

In article <[e-mail]> [e-mail] (Kent Sandvik) writes:
>
>   Sometimes I just hope that AEs would be the glue, and we had various
>editors, compilers and development environments who talk with each
>other using the same protocol. I have a dream..
>--

It would be nice. I think this is still a fairly long way off. One reason:
using AppleEvents is *slow*. I'm sure it is better on an all-Ethernet network,
but perhaps not *that* much better. Until everyone has a PowerPC running at
the speed of a Cray Y-MP, I can't see using applications controlled entirely
by AppleEvents.

Then again, maybe Apple knows something I don't (quite likely in fact...) : >

>                                              Cheers, Kent
>


- --
Paul R. Potts, Software Designer --- [e-mail] <--- me!

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 29 May 92 22:01:39 GMT
Organization: MacDTS Mongols

In article <[e-mail]>,
[e-mail] (Paul Potts) writes:
>
> In article <[e-mail]> [e-mail] (Kent Sandvik) writes:
> >
> >   Sometimes I just hope that AEs would be the glue, and we had various
> >editors, compilers and development environments who talk with each
> >other using the same protocol. I have a dream..
> >--
>
> It would be nice. I think this is still a fairly long way off. One reason:
> using AppleEvents is *slow*. I'm sure it is better on an all-Ethernet network,
> but perhaps not *that* much better. Until everyone has a PowerPC running at
> the speed of a Cray Y-MP, I can't see using applications controlled entirely
> by AppleEvents.

   Note that you could have all components on your *own* machine, no LocalTalk,
no Ethernet, no TokenTalk... I don't think AEs are that slow, they have
limitations, like max 4k transfers, but then again smart AEs don't need to
pump data, just send over pointers to data.
- --
                                              Cheers, Kent


+++++++++++++++++++++++++++

From: [e-mail] (Steve Dakin)
Date: 28 May 92 16:51:32 GMT
Organization: Oceania Health Care Systems

In article <[e-mail]> [e-mail] (Cory
Kempf) writes:
>
> somewhere convenient (the worksheet) type:
>
> file <filename>; line xxx <enter>

Still not as convenient as a menu command (with key equivalent), but hey! I'll
take it (do I have a choice? :^).

- -Steve
- --
    Steve Dakin                      Oceania Health Care Systems
 [e-mail] (NeXT mail)       Palo Alto, CA [phone]
 [e-mail]                  "That one deserves a ... WOW!"

+++++++++++++++++++++++++++

From: [e-mail] (Fred Walsteijn)
Date: 31 May 92 20:11:06 GMT
Organization: Physics Department, University of Utrecht,  The Netherlands

In <[e-mail]> [e-mail] (Steve Dakin) writes:

>In article <[e-mail]> [e-mail] (Cory
>Kempf) writes:
>>
>> somewhere convenient (the worksheet) type:
>>
>> file <filename>; line xxx <enter>

>Still not as convenient as a menu command (with key equivalent), but hey! I'll
>take it (do I have a choice? :^).

There are a number of easy ways to select a line by number in MPW.
Here are two of them, each working on the *active* window:

1. select "Find" from the "Find" menu;
   click the "selection expression" radio button;
   type the line number;
   click OK.

2. modify your Startup scripts to include:
AddMenu Find 'Line #.../L'    'menuline'
AddMenu Find 'What Line?'    'ALERT -s "Line #`position -l "{active}"`"'

Herein "menuline" is a script, which you should store in the MPW Scripts
folder. It should contain:
- ------------------------
set exit 0
set theline "`request 'Line number?'`"
Exit if {theline} == ""
find "{theline}" "{Active}"
set exit 1
- ------------------------

Try it !!!
You can use Command-L as a shortcut.
- -----------------------------------------------------------------------------
Fred Walsteijn                                | Internet: [e-mail]
Institute for Marine and Atmospheric Research | FAX:      [phone]
Utrecht University, The Netherlands           | Phone:    [phone]

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 31 May 92 22:39:35 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Kent Sandvik) writes:
>
> In article <[e-mail]>,
> [e-mail] (Paul Potts) writes:
> >
> > In article <[e-mail]> [e-mail] (Kent Sandvik) writes:
> > >
> > >   Sometimes I just hope that AEs would be the glue, and we had various
> > >editors, compilers and development environments who talk with each
> > >other using the same protocol. I have a dream..
> > >--
> >
> > It would be nice. I think this is still a fairly long way off. One reason:
> > using AppleEvents is *slow*. I'm sure it is better on an all-Ethernet
network,
> > but perhaps not *that* much better. Until everyone has a PowerPC running at
> > the speed of a Cray Y-MP, I can't see using applications controlled entirely
> > by AppleEvents.
>
>    Note that you could have all components on your *own* machine, no
LocalTalk,
> no Ethernet, no TokenTalk... I don't think AEs are that slow, they have
> limitations, like max 4k transfers, but then again smart AEs don't need to
> pump data, just send over pointers to data.

Sorry, I stated the wrong value, Greg Robbins told me that it's 32k/64k (dunno,
I don't personally know why we have this dualistic value, but someone more
knowledgeable concering AEs might have the answer.

Anyway, my point was that I don't see a future where AEs carry around file
information, instead pointers where to fetch the data (file system yak,
data base, better, object oriented database with persistant data, future).
- --
                                              Cheers, Kent



---------------------------

End of C.S.M.P. Digest
**********************